Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Editorial: Use <code> for values from other specifications #2594

Merged
merged 1 commit into from
Jan 19, 2022
Merged

Editorial: Use <code> for values from other specifications #2594

merged 1 commit into from
Jan 19, 2022

Conversation

gibson042
Copy link
Contributor

From original discussion at tc39/ecma402#624 (comment) .

@gibson042 gibson042 mentioned this pull request Dec 1, 2021
Merged
@bakkot bakkot added the editor call to be discussed in the next editor call label Dec 1, 2021
@bakkot
Copy link
Contributor

bakkot commented Dec 1, 2021

~ is used in 262 for values which get passed around and manipulated by algorithm steps, which these aren't. An explicit <code> tag seems like the right thing to me.

@gibson042
Copy link
Contributor Author

@bakkot is there editor consensus on that? Whether or not external-specification file names/processor instructions/etc. would count as "Values which are internal to the [ECMA-262] specification" is not obvious to me and <code> looks worse in my opinion, but I have no problem switching.

@bakkot
Copy link
Contributor

bakkot commented Dec 7, 2021

@gibson042 There is consensus among the ecma-262 editors that ~ should only be used for internal values, and that the names of files in external specifications (and similar) are not values in that sense, yes.

We didn't discuss the rendering explicitly; if you have an alternative rendering you'd prefer, feel free to suggest it.

@bakkot bakkot removed the editor call to be discussed in the next editor call label Dec 8, 2021
@gibson042
Copy link
Contributor Author

That's good enough for me; updated accordingly.

@gibson042 gibson042 changed the title Editorial: Treat values from other specifications as internal values Editorial: Consistently represent values from other specifications Dec 30, 2021
gibson042 added a commit to gibson042/ecma402 that referenced this pull request Jan 13, 2022
@gibson042
Consistently reference UCD files
6c13224 
Ref tc39/ecma262#2594
@michaelficarra
Copy link
Member

@gibson042 Can you update this PR to format the referenced files with links as in #2515 (comment)?

@gibson042 gibson042 force-pushed the 2021-12-external-spec-values branch from b389e09 to 4c8e33f Compare January 19, 2022 21:14
@gibson042
Copy link
Contributor Author

@michaelficarra done

@bakkot bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Jan 19, 2022
@ljharb ljharb changed the title Editorial: Consistently represent values from other specifications Editorial: Use <code> for values from other specifications Jan 19, 2022
@ljharb ljharb force-pushed the 2021-12-external-spec-values branch from 4c8e33f to 41dac9e Compare January 19, 2022 22:11
@ljharb ljharb merged commit 41dac9e into tc39:main Jan 19, 2022
gibson042 added a commit to gibson042/ecma402 that referenced this pull request Mar 25, 2022
@gibson042
Editorial: Use <code> for values from other specifications
746b610 
Ref tc39/ecma262#2594
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@michaelficarra michaelficarra michaelficarra approved these changes

@bakkot bakkot bakkot approved these changes

@ryzokuken ryzokuken ryzokuken approved these changes

Assignees
No one assigned
Labels
editorial change ready to merge Editors believe this PR needs no further reviews, and is ready to land.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@gibson042 @bakkot @michaelficarra @ryzokuken @ljharb